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Abstract 

In this paper we report on our re-engineering effort to refactor and unify two somewhat 
disjoint Java distributed middleware technologies - Jini and JMS - used in the implemen- 
tation of the Demand Migration System (DMS). In doing so, we refactor their parent De- 
mand Migration Framework (DMF), within the General Intensional Programming System 
(GIPSY). The complex Java-based GIPSY project is used to investigate on the intensional 
and hybrid programming paradigms. 

1 Introduction 

The GIPSY research prototype system |26J (see Section [2]) is a collection of replaceable Java 
components arranged primarily into three main packages - the collection of compilers for the 
programming languages of interest (GIPC - core - Lucid-based intensional dialects [3], and 
hybrid dialects, primarily mixing Lucid code and Java code to various degrees), runtime pro- 
gramming environment (RIPE) (currently a loose set of user interaction components), and the 
run-time systems - the general eduction engine (GEE). We focus on some aspects of the latter 
in this paper, specifically its distributed subcomponents that implement two instances of the 
demand-migration system (DMS) using two distributed Java middleware technologies, namely 
Jini and JMS for comparative studies of evaluation of hybrid programs to gain insight on the 
technologies and various their parameters from programmability to scalability metrics among 
others. Here we report some of our findings through development and experiments. 

Problem Statement One of the main reasons necessitating this study is the hybrid inten- 
sional programming aspect the the GIPSY platform is there to investigate among other things. 
Lucid programs are naturally parallel and expressive [31 |31] as well as context-oriented with 
contexts as first class values [321 127j . Yet, in itself Lucid is rather simple functional language 
for computation, and does not have rich I/O and other support, so it should rely on the ex- 
isting libraries and frameworks when such needs arise leading the way to hybrid programming 
paradigms involving a Lucid dialect and Java in our case. Earlier (while still very valuable to 
the community, but relatively non-scalable and umaintainable) solutions, were proposed and 
their enhancement with hybridification of Lucid and C [9] [10] or later C-|— |- [19] . Since GIPSY's 
architecture was first proposed and evolved in the past 10 years to be extendable and component- 
based, hybrid prototype dialects emerged combinding Java and Lucid - JLucid (Lucid program 
primarily calls only Java methods). Objective Lucid (Lucid to access to object properties of Java 
objects) |J,5j and later JOOIP (Java-based 00 Intensional Programming) language [33j that en- 
abled bidrectional Lucid being able to access Java members and, at the same time, Java classes 
could contain fragments written in Lucid in them. (Further work in programs involves exten- 
sion of these in the form of Forensic Lucid [17] and MARFL [T6] ) . To support the evaluation of 
programs written in these hybrid dialects, the runtime (GEE) of GIPSY has to scale to be able 
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not only to locally compute light-weight Lucid fragments locally, but also compute the hybrid 
"heavy" Java fragments - given the latter can take a lot of computation and I/O resources, 
and natural parallelization of Lucid, the hybrid components are proposed to be evaluated dis- 
tributively. Then the problem becomes which distributed middleware technologies to pick. As 
a proof of concept, the DMF was defined in Java and was implemented using two different Java 
middleware technologies, Jini (by Vassev et al. |29j) and JMS (Pourteymour [5^). But those 
two were development in the simulated prototype environment, relatively isolated from the core 
GIPSY project and from each other. 

Proposed Solution To enable consistent comparative studies of Jini and JMS in the GIPSY 
multi-tier environment and hybrid language paradigms [2H \TE\ [7] for points of scalability , 
usability, programmability, deployment, and other aspects, we unify the two Java implementa- 
tions of Jini and JMS DMS under GEE and its multi-tier architecture and redefine the practical 
meaning of certain of its components and do extensive testing of both. Hereafter, we report on 
our experience in this regard. 

Organization We proved the necessary background of the Java-based GIPSY project and its 
distributed middleware technologies used in Section [2] We then describe the objectives of this 
work in Section [3. 1| and present the methodology and the approach in Section [3j and finally we 
conclude in Section [H 

2 Background 

The General Intensional Programming System (GIPSY) provides a platform to investigate the 
possibilities of the intensional programming |20j . The intensional programming model, in the 
sense of Lucid, is a declarative and functional programming language paradigm where the iden- 
tifiers are evaluated in multidimensional context spaces. The GIPSY compiler translates any 
flavor of intensional program into a source-language independent GIPL program, and the GIPSY 
runtime system executes the GIPL program using an evaluation model called eduction. In the 
demand-driven eduction model, an initial demand requesting the value of a certain identifier 
is generated, and to consume this demand, new demands are generated to request the values 
of the identifiers constituting the expression defining the initial identifier, and similarly these 
demands further generate new demands until eventually some of the demands are evaluated and 
propagated back in the chain of demands, so that the identifiers whose value depend on them can 
be evaluated in turn, and eventually the initial identifier is evaluated [20]. This demand-driven 
eduction model naturally supports distributed execution of intensional programs \10\ I19|. 

The Demand Migration Framework (DMF) for the GIPSY runtime system was proposed for 
the distributed and demand-driven execution of intensional programs by Vassev et al. [26 t [30 1 129 1 
[28l [22l [15], and two principle Demand Migration Systems (DMS) as of this writing - based on 
Jini and JMS Java middleware technologies were provided to implement the DMF |231 [M] . The 
basic idea of the DMF is to provide a generic framework defining interface to migrate/propagate 
demands among distributed demand generators and demand workers, where the generators 
generate demands and the workers compute the demands. 

A follow up work by Ji et al. [llj further streamlined the code for unification while performing 
scalability studies for the the Jini and JMS implementations of DMS in GIPSY (see Section [4|. 

We briefly introduce the Jini DMS and the JMS DMS architectures in the sections that 
follow. 
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2.1 Jini DMS 

Jini is a Java-based and service-oriented middleware technology for building distributed systems 
consisting of Jini services and clients |12l [H [6]. Now officially known as Apache River [2j, Jini 
defines a set of specifications and provides implementation of several basic services such as 
lookup discovery, leasing and transaction services. It also provides a Java implementation of 
the Tuple Space called the JavaSpace service that enables distributed Jini clients to read, write 
and remove serialized Java objects stored in the shared object repository. JavaSpace supports 
object persistence so that when restarted, the objects stored in the JavaSpace can be recovered. 

The Jini DMS of the GIPSY runtime system was implemented by Vassev with his proposal 
of the first Demand Migration Framework (DMF) [291 EH] • As shown in Figure [T| the Jini 
DMS consists of Demand Generators Demand Workers, Jini Transport Agent (Jini TA) and 
JavaSpace. The Demand Generators and Workers communicate among each other by sending 
and reading demands into and from the JavaSpace with the aid of the Jini TA. A demand is a 
serialized Java object containing information for the evaluation of Lucid identifiers that require 
functional computation. A typical demand-migration process is as follows: 

1. when parsing the abstract syntax tree of a hybrid Lucid program, the Demand Genera- 
tors encounter identifiers whose values depend on certain functional computations, so the 
Generators generate pending demands to request these computation and use the TA to 
send those pending demands into the JavaSpace; 

2. the Demand Workers then use the TA to pick up the pending demands from the JavaSpace 
and carry out the functional computations requested, and send the computed demands 
back to the JavaSpace; 

3. the Demand Generators then use the TA to pick up the computed demands from the 
JavaSpace and retrieve the values of the identifiers. 

The Jini TA in Figure [l] consists of Jini TA proxies and a Jini TA backend. Each Demand 
Generator or Worker can obtain a Jini TA proxy object using the Jini lookup discovery service, 
and uses this TA proxy to communicate with the remote Jini TA backend via remote method 
invocation. To write a demand into the JavaSpace, once invoked remotely by the Demand 
Generator or Worker, the Jini TA backend uses a local Demand Dispatcher object to wrap the 
demands as JavaSpace entries and send the entries into the remote JavaSpace. The reference 
to the remote JavaSpace service held by the Demand Dispatcher is also looked up via the Jini 
lookup discovery service. Similarly, once invoked remotely to read a demand from the JavaSpace, 
the Jini TA backend uses the Demand Dispatcher object to retrieve the corresponding JavaSpace 
entry and unwrap it, and returns the demand to the remote Demand Generator or Worker. 

The separation of the Jini TA into proxies and the remote backend it allows diverse Jini TA 
implementations to be integrated into the system without affecting existing components, and 
may increase system availability by allowing the Demand Generators and Workers to connect 
to any TA registered in the Jini lookup discovery service. However, its disadvantages are that 
the additional remote method invocation is redundant that it increases communication cost and 
undermines performance. 

2.2 JMS DMS 

JMS is short for Java Message Service that is a Java-based and message-oriented middleware 
technology [H [T31 15] . It defines a set of API specifications and has several implementations such 
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Figure 1: Jini DMS architecture 



Open Message Queue and JBoss Messaging. Basically a JMS implementation is a JMS broker 
providing messaging services to its clients. The JMS clients fall into two domains: message pro- 
ducer and consumer, and message publisher and subscriber. The producer/consumer domain 
is for end-to-end messaging, meaning that each message is sent by one producer, stored in the 
message queue in the broker, and received by only one consumer; whereas the publisher /sub- 
scriber is for broadcast messaging, in which each message is sent by one publisher, but can be 
received by multiple subscribers. Compared to Jini JavaSpace, JMS broker provides additional 
services to ensure availability and reliability such as delicate memory management, flow control, 
various acknowledgment models and better polished transactions. JMS also supports message 
persistence. 

The JMS DMS was first implemented by Pourteymour \22\ [23l based on the message 
producer /consumer model. The alternative publisher/subscriber model was not adopted because 
it does not allow newly registered subscribers to receive messages that were published before 
their registration, whereas the GIPSY must allow workers to pick up pending demands in the 
form of messages sent at anytime. As shown in Figure [2| the JMS DMS consists of Demand 
Generators, Demand Workers, JMS TAs and the JMS broker service. Similar to the Jini DMS, 
the Demand Generators generate demands and the Workers compute the demands, and the 
demands are migrated among them via the TAs and the JMS broker service. However, in this 
JMS DMS, to send a demand passed by the Demand Generator or Worker, the JMS TAs wrap 
the demands into object messages and send them directly into the message queues managed by 
the broker; to read a demand, the JMS TAs directly read object messages from the message 
queues, unwrap and return the demands to the Demand Generator or Worker. Compared to the 
Jini DMS, the JMS DMS has a simpler TA architecture without unnecessary communication 



4 



Uniform Invocatfon of Jini and JMS DMSs in GIPSY 



Ji, Mokhov, Paquet 



cost, and it does not have a concrete Demand Dispatcher to wrap around the message queue 
since the JMS API and broker was reckoned as the role of the Demand Dispatcher. However, 
since the JMS TA in the JMS DMS is directly instantiated by the Demand Generator or Worker, 
once the TA implementation is changed, the Java source code of the existing components will 
be affected, which is inconvenient to add new TA implementations that are based on different 
middleware technologies. 



Demand 
Generators 



JMSTA 



Demand 
Workers 



JMSTA 




Figure 2: JMS DMS architecture 



3 Methodology 

We studies the original implementations of Jini and JMS DMS to be able to run both consistently 
or even concurrently within one GIPSY computing network instance. With this preliminary 
study we defined a number of required objectives related to the actual refactoring, as well as 
identifying which technology is more appropriate than the other and under which condition in 
the consistent uniform setup; including common interfaces, glue, data structures and the like. 



3.1 Objectives 

• Make JMS [25J and Jini p3] look similar, i.e. be a part of the same interchangeable 
framework's implementation. 

• Redefine the roles of Demand Dispatcher and the Transport Agent (see Figure [s]) for the 
dispatcher to be more of decision maker and a scheduler for the generators, etc. rather 
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than being attached to the demand store. 

• Compare Jini and JMS vs JVM performance and scalabihty of computation. 

• Compare programmabiHty of the two APIs. 

• Compare ease of depfoyment and startup of JMS and Jini from the same common point. 
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Figure 3: Demand Generator and Demand Dispatcher relationship 



3.2 Making Jini and JMS similar 

Before the refactoring process, the class diagram of the Jini and JMS DMSs is shown in Figure |4} 
In this class diagram, the Jini Demand Dispatcher communicates directly with the JavaSpace, 
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and is used by the JTABackend that is remotely invoked by the JINITransportAgentProxy. 
The JMSTA communicates with Message Queue directly and had no DemandDispatcher. The 
JINITransportAgentProxy and the JMSTA inherit different interfaces as they expose too much 
middleware-dependent features, such as the UUid in Jini and the connection setup phase in JMS, 
and therefore each DMS has their own Demand Generator and Worker since the Generator and 
Worker instantiate their TAs directly and use them in a middleware-dependent way. 



«interface» 
■DemandDispatcher 



+whteDemand(in oDemand : IDemand) : DemandSignature 

^-writeResult(in oDemand : IDemand) : DemandSignature 

^-readOemandQ : IDemand 

+readDemandlfExists() : IDemand 

+readResult(in oSig : DemandSignature) : IDemand 

+readResultlfExists(in oSig : DemandSignature) : IDemand 



«interface» 
ITransportAgent 



+getDemand() : IDemand 

+getDemandlfExists() : IDemand 

+getResult(in oSig : DemandSignature) : IDemand 

+getResultl{Exists(m oSlg : DemandSignature) : IDemand 

+setDemand(in oDemand : IDemand) : DemandSignature 

+setResult(in oDemand : IDemand) : DemandSignature 
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Figure 4: DMS class diagram before refactoring 

The refactoring began with creating a new class called JiniTA, moving the original busi- 
ness logic of the DemandDispatcher into this JiniTA, and updating all the references to the 
original DemandDispatcher by pointing them to the new JiniTA. Then we encapsulated all 
the middleware-dependent logic, such as JMS connection setup and teardown, inside each TA 
implementation, and made them directly inherit the ITransportAgent interface. Having done 
so, we removed all the TA-implementation-dependent logic, such as TA instantiation, from the 
Demand Generators or Workers, so that they only reference ITransportAgent only. Then we 
used DemandDispatcher to delegate ITransportAgent, and replaced the usage of ITransportA- 
gent with IDemandDispatcher inside the Demand Generator and Worker, so that the Demand 
Generators or Workers now talks to IDemandDispatcher only and in the future we could easily 
add scheduling logic into the DemandDispatcher to decide when, where and using what TA 
to send or receive demands. The class diagram of the DMS after our refactoring is shown in 
Figure [5} We also unified the demand classes we use and separate them into subclasses due to 
their different purposes, such as procedural identifier evaluation, intensional identifier evaluation, 
runtime- resource acquisition and system management, as shown in Figure [6j 

To ease the addition and switching of TA or Demand Dispatcher implementations, we use 
Java Refiection to instantiate each TA or Demand Dispatcher implementation by the name. 
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+setResult(in oDemand : IDemand) : DemandSignature 
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Figure 5: DMS class diagram after refactoring 
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Figure 6: class diagram of demands 
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where the name of the implementation is a character string passed via network or stored in 
files. In this way the two DMSs are interchangeable without changing the Java source code of 
the Demand Generator and the Demand Worker, so that we can use the same set of Demand 
Generators and Demand Workers to a comparative study of the two DMSs. With proper testing 
and upon approval from all group members, we committed the changes and cleaned up the 
affected code remained. 

4 Results 

We compared the following three aspects of the Jini and JMS DMSs based on our refactoring 
work. 

4.1 Ease of programming 

In our experience, the programming of Jini application requires the knowledge of several sep- 
arate but also correlated Jini concepts and services, such as service lookup discovery, leasing, 
JavaSpace and transaction. Such knowledge requires time and effort to collect, study and put 
into practice, especially if additional quality of service (QoS) is required. For example, Jini 
does not provide additional memory management besides the memory tuning available to the 
Java Virtual Machine (JVM), therefore if stronger memory management mechanism is required, 
programmers will have to code their own Jini extension to enhance memory management. In 
contrast, JMS is a mainstream middleware technology and has relatively integrated services, 
more QoS choices, well managed documentation and easily understandable tutorials, which is 
easier for programmers to learn and put into practice. 

4.2 Ease of deployment 

Jini requires only a set of .jar and configuration files to start its services, therefore has a light 
weight (the size of all .jar files is less than 4 MB) and can be easily deployed across different plat- 
forms, as long as Java is installed in the machines. In contrast, JMS requires platform-dependent 
executable binary files, such as .exe files in Windows, to start and manage the broker service, 
therefore it has a larger size (in the case of 32-bit Windows version, the size of all executable 
files and .jar files is around 20 MB), and requires those plat-form dependent executable files to 
be deployed across different platform. 

4.3 Runtime issues 

We tested that when the Jini DMSs was storing increasing amount of demands, the Jini DMS 
would run out of memory and crash in the end, even if the data persistence feature was turned 
on. This shows the storage capacity of the Jini JavaSpace is constrained by its memory, and 
it provides no mechanism to prevent JVM crash. In contrast, the JMS DMS with message 
persistence turned on can swap persistent messages into its persistent storage, such as files, to 
reduce its memory usage once the memory usage exceeds certain threshold. Therefore when the 
GIPSY runtime system is facing increasing amount of demands, the JMS DMS with message 
persistence is a better choice when the system availability is the dominant concern. 

However, when comparing system performance in the sense of throughput of concurrent 
Pi calculation demands when the demands were generated by a multi-threaded Generator and 
computed by multiple Demand Workers distributed in different computers with maximumly 
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two Workers per computer, we found that as the number Workers increases, the Jini DMS 
provided a higher throughput than the JMS DMS, and the JMS DMS reached its throughput 
saturation when there were 10 Workers deployed. The test result is shown in Figure [7| and 
the test was perform in a lab with computers with the same hardware and operating system 
environment shown in Figure [T] These computers and their corresponding switch ports have 
100 Mbps maximum speeds, with each machine connected to one switch port and all of them on 
the same subnet and VLAN. This test shows that in the sense of throughput, the Jini DMS is 
a better choice than the JMS DMS. We also found that for each Demand Generator or Worker 
connection, the Jini DMS uses one thread to handle each connection, whereas the JMS DMS 
uses two threads. 

All the above differences show that when deployed in managed network, Jini is more suitable 
for DMS requiring high throughput but low memory storage and low reliability, whereas JMS 
is suitable for DMS requiring high reliability and availability. 



throughput of Pi-calculation demands 

50 -1 




1 1 1 1 1 1 1 [— 

2 4 6 8 10 12 14 16 

Number of DWTs 



Figure 7: throughput of Pi calculations of the two DMSs 
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Table 1: Hardware and operating system environment 



f \ o AT 

Uh iName 


Microsoit Windows 7 Enterprise 


Version 


Version 6.1.7600 Build 7600 


System iype 


XoD-based PC 


Processor 


lntel(Rj Lore(lM)2 CPU 6300 @ 1.86GHz, 
1862 MHz, z Core(sj, 2 Logical Processor (sj 


Installed RAM 


2.00 GB 


Total RAM 


2.00 GB 


Available RAM 


1.06 GB 


Total Virtual Memory 


4.00 GB 


Available Virtual Memory 


2.58 GB 


Page File Space 


2.00 GB 



5 Conclusion 

We have successfully did the POC integration of the two middleware technologies implemen- 
tations based on Jini and JMS available to the GIPSY run-time system. In the future work 
we plan to continue refactoring and cleaning up the other technologies within GIPSY to work 
together in unison. It is evident, that Jini appears to be easier to work with for development 
and deployment, but its memory-bound scalability is more problematic than that of JMS, so 
JMS-based implementation is general more reliable, but Jini DMS offers higher throughput over 
JMS. For in-depth results of the initial study on various scalability metrics pleas refer to |llj . 
Some significant redesign was also necessary to make the two implementations work together 
consistently, with a potential payoff any new, better or worse, implementations for comparative 
studies like we did, will be much more manageable. 

5.1 Future work 

There is a lot of work to be done; our immediate future attention will be the item (1) below to 
expand our distributed testing environment followed by other proposed items: 

1. Various JVMs in Linux and MacOS X distributed testing environments and clusters 

2. Comparative study for Web Services-based implementation 

3. Long-running distributed computation processes (e.g. MARF pattern recognition pipeline 
with very large data set over GIPSY) 

4. Expand the architecture to mobile Java platforms 
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A How to run the Jini DMS and the JMS DMS in the GIPSY 
project 

This documents introduces the steps to deploy and start the GIPSY runtime system in 32-bit 
Windows. 



1. check out the GIPSY project jl4|. The project is an Eclipse project so you can simply 
imported into Eclipse IDE for Java Developers [5J. However, before you import it into 
Eclipse, remember to stop Eclipse from cleaning the bin folder as all the DMS executables 
are there. For example, in the case of Eclipse Helios, once the IDE is open, go to Windows- 
^Preferences-^Java-^Compiler-^Building, and uncheck the option "Scrub output folders 
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when cleaning projects", and go back to the menu bar, chck Project, and uncheck the 
option "Build Automatically" so that you will need to build the project manually. Then 
you can import the GIPSY project and build it manually. 

2. Once the GIPSY project is built, you can go to the project's home folder, then go to the 
directory 
bin 

multitier 



3. If you want to start Jini DMS, open StartGMTNode.config, and set the value of the 
property gipsy.GEE. multitier. Node. DSTConfigs as ../jini/DST.config 

4. If you want to start JMS DMS, open StartGMTNode.config, and set the value of the 
property gipsy.GEE. multitier. Node. DSTConfigs as ../jms/DST.config 

5. Double click startGMTNode.bat. 



B How to run the Jini DMS in the GIPSY project 

This document introduces the steps to compile and run the Jini code in the GIPSY project in 
Windows XP. To use this guide, readers are required to have basic Java and Eclipse experience, 
basic Jini knowledge (for example, service, lookup, JavaSpace, etc), and the basic understanding 
of the GIPSY project structure. 



1. Get and install the appropriate software, and import the GIPSY project fll]. NOTE: If 
the software below cannot be found online, please check the GIPSY tools repository 

(a) JDK 6 update 14 or later (|http : // j ava . sun . com/ j avase/downloads/ index . j sp ) . 

It is better to set the JAVA_HOME environment variable. 

(b) Eclipse IDE for Java Developers [5]. Unpack the IDE, open it and import the GIPSY 
project from the GIPSY CVS into the Eclipse. 

(c) Jini Technology Starter Kit v2.1 [12]. The installation should require no administrator 
accounts. The term JINI_HOME would be used in this manual to refer the installation 
directory. 

2. Compile the Jini code of the GIPSY project NOTE: Point 1 and 2 should be done already 
in the GIPSY project when you get it. 



(a) Copy the jini-core. jar and jini-ext. jar from JINI_HOME/lib into the [gipsy/ 
Ilib 

(b) Configure the project Build Path by adding the above jars inside lib through "Add 
JARs" 

(c) Build the project automatically or manually. 
3. Start the Jini service 



(a) Go to JINI_HOME/installverif y, and double-click the Launch All shortcut. The 
shortcut should launch a service window and a Service Browser window. 
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(b) In the Service Browser window, click the "Registrar", and select the registrar rep- 
resenting your computer. Then there would be 6 services appear in the "Matching 
Services" area, including JavaSpace05, LookupDiscoveryService, ServiceRegistrar and 
Tr ansactionManager . 

(c) Leave the two windows open and do not touch them unless you want to shut down 
all the services. 

4. Run the code requiring only JavaSpace. NOTE: Currently there are two groups of Jini 
scenarios. The first one consists of DemandDispatcher, DemandDispatcherClient and the 
DemandDi spat cher Agent under the gipsy . GEE . IDP package. The second scenario consists 

of the gipsy . GEE. IDP .DemandDispatcher, and the DGT class in the gipsy . GEE . IDP . DemandGenerator . s: 

package, and the Worker class in the gipsy . GEE . IDP . DemandGenerator . simulator . j ini 

package. 

(a) Open Eclipse and run the classes within the same groups mentioned above with the 
mainO method. 

5. Run the code requiring both JavaSpace and RMI 



(a) Use command window to go to the gipsy/bin directory. 



(b) Open the ,start JiniHTTPServer . bat in edit mode, and check if all the paths are 
correct. 



startJiniHTTPServer.bat 



start JiniRMID . bat 



(c) Double-click the 

(d) Double-click the 

(e) Open Eclipse and run the 

gipsy . GEE. IDP .DemandGenerator . j ini .rmi . JINITransport Agent, and the gipsy . GEE. IDP .Demam 

and the DGT in the gipsy. GEE. IDP. DemandGenerator. simulator package. 

Note: 

Please make sure that the Istart JiniHTTPServer . bat) and the Istart JiniRMID . bati 
are in the gipsy/bin folder. If they are missing, please refer to the following con- 
tent. Please make sure the settings in the content are consistent with your own JRE 
directories as shown in Figure [8] and Figure |9j 

set RUNTIME. JAR= "D:\Progr am Files\Java\jre6\lib\rt . jar" 
set JINIHOME_BACKSLASH="D:\Program Files\jliii2_l" 

set JINI_CLASSPATH= . ; '/.RUNTIME. JAR'/. ; '/.JINIHOME.BACKSLASH'/AlibX j ini-core . j ar ; '/.JINIHOME.BAC 
KSLASHy.\lib\jini-ext. jar;"/,JINIHQME_BACKSLASH'/.\lib\reggie. jar;y.JINIHOME_BACKSLASH'/.\lib-d 
l\reggie-dl . j ar ; '/.JINIHOME.BACKSLASH'/.MibXmahalo . j ar ; y.JINIHOME.BACKSLASH'/.Mib-dlNmahalo 
-dl . j ar ; 7, JINIHQME_BACKSLASHy.\lib\outr igger . j ar ; 7, JINIHOME_BACKSLASHy.\lib-dI\outrigger-dl . j 
ar;'/.JINIHOME_BACKSLASHy,\lib\tooIs. jar;y.JINIHOME_BACKSLASHy.\Iib\suii-utiI. jar; 

java -jar -classpath y.JINI_CLASSPATHy, y.JINIHOME_BACKSLASHy.\Iib\tools . jar -port 8085 -dir . 
-verbose 

Figure 8: startHTTPServer.bat 



rmid - J-D java. security .policy=gipsy/GEE/IDP/ conf ig/jini .policy 



Figure 9: startJiniRMID.bat 
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